AI Agent系统设计方法论#
一句话答案#
Agent 系统设计的套路是「先问要不要 Agent → 再定架构与规划范式 → 自底向上搭七层（工具/记忆/知识/控制/评测/可观测/成本安全）」；面试开放题答得好的关键是先界定边界和非功能需求，再按分层框架展开，每个选型都给出 tradeoff 和退路，而不是一上来就画 ReAct 循环。
核心要点
1. 第一步：要不要用 Agent（最容易被追问的决策）#
不要为了用 Agent 而用 Agent。按”任务确定性 / 步骤是否动态”决策：
任务是否需要"动态决策下一步"？
├── 否，单轮问答 → 纯 LLM / Prompt
├── 否，流程固定可枚举 → Workflow（固定流水线/状态机）
├── 是，但只是查资料 → RAG（检索增强）
└── 是，需自主规划+调工具+根据观察调整 → Agent
└── 单 Agent 扛不住（角色多/职责杂）→ 多 Agent面试金句：“Agent 的成本是不确定性——延迟高、token 贵、难调试。能用 Workflow 解决就别上 Agent，能规则化的决策（如工具选择）就别交给 LLM。“
2. 第二步：架构与规划范式选型#
| 维度 | 选项 | 何时用 |
|---|---|---|
| 规划范式 | ReAct / Plan-and-Execute / Reflection | 简单交互 ReAct；长任务先 Plan 再 Execute；高质量要求加 Reflection |
| 编排架构 | 单 Agent / Supervisor-Worker / 去中心化多 Agent | 职责单一用单 Agent；多角色协作用 Supervisor-Worker；对等协商用去中心化 |
| 决策方式 | LLM 决策 / 规则引擎 / 混合 | 可枚举的决策走规则（快、可测、确定），开放决策才交 LLM |
详见 Agent设计模式、多Agent协作架构、意图识别与任务路由。
3. 第三步：自底向上的七层设计框架#
记忆口诀「工记知，控评观本」——设计/答题时逐层过一遍：
| # | 层 | 关键决策 | 对应笔记 |
|---|---|---|---|
| 1 | 工具层 | Schema 设计、权限分级、MCP 标准化、幂等与重试 | [Function Calling与工具编排](/topics/ai-llm/Function Calling与工具编排)、MCP协议原理 |
| 2 | 记忆层 | 工作/短期/长期三层、token 预算、压缩、写回策略 | Agent记忆与上下文工程、长期记忆治理与多租户隔离 |
| 3 | 知识层 | RAG 分块/混合检索/重排、知识更新与增量索引 | RAG架构与实现、RAG分块与召回策略、[Agentic RAG与高级检索](/topics/ai-llm/Agentic RAG与高级检索) |
| 4 | 控制层 | Reflection 质量回环、结构化输出、Guardrails 护栏 | Reflection与自我修正模式、结构化输出与约束解码、Guardrails与输出安全护栏 |
| 5 | 评测层 | 离线评测集、在线指标、LLM-as-Judge、回归 | Agent评测平台设计、LLM评测方法 |
| 6 | 观测层 | Trace（每步可追溯）、Metrics、Checkpoint 断点续跑、降级 | Agent可观测性与质量保障、[Agent Runtime与Checkpoint机制](/topics/ai-llm/Agent Runtime与Checkpoint机制) |
| 7 | 本（成本/安全）层 | 模型级联、语义缓存、流式、并行；注入防御、多租户隔离与配额 | AI应用成本与质量量化治理、[Agent安全与Prompt Injection防御](/topics/ai-llm/Agent安全与Prompt Injection防御)、多租户隔离与配额治理 |
4. 非功能需求清单（开放题加分项）#
面试官最爱追的不是功能，是这些：延迟（首 token / 端到端）、成本（单次 query 价格）、准确率/幻觉率、并发、可观测、降级、安全合规、多租户。开场就主动锁定这些约束，能直接把答案拉到资深档。
5. 通用降级与”退路”思维#
每个外部依赖都要有退路，这是生产 Agent 与 Demo 的本质区别：
LLM 失败 → 规则路由 / 缓存兜底 / 降级话术
检索失败 → 多路检索互为备份（向量挂了走 BM25）
重排失败 → 关键词打分兜底
工具失败 → 备选工具 → 纯 LLM 回答 → 转人工
反思超预算 → 跳过反思直接输出案例一：企业智能客服 Agent（检索+对话型，高并发）#
场景：电商客服，处理订单查询、退换货、政策咨询，高并发、低延迟、强合规。
| 设计层 | 决策 | 理由 / tradeoff |
|---|---|---|
| 要不要 Agent | 混合：意图路由用规则+小模型，复杂工单才进 Agent | 80% 是高频简单问题，规则/RAG 直接答；只有跨域复杂问题上 Agent，控成本控延迟 |
| 架构 | 单 Agent + 意图路由，ReAct | 角色单一，无需多 Agent；路由先分流 |
| 工具层 | 查订单/查物流/发起退款（退款=write 权限需确认） | 高风险工具分级：只读自动、退款需用户二次确认 / 人工审批 |
| 记忆层 | 短期=本次会话；长期=用户历史订单与偏好 | 多轮上下文要记住”刚才问的那个订单” |
| 知识层 | 政策文档 RAG，混合检索+重排 | 政策更新频繁，增量索引；答案须可溯源到原文 |
| 控制层 | 输出 Guardrails（话术合规、PII 脱敏）+ 不支撑就拒答 | 客服场景合规红线高，宁可转人工不可乱答 |
| 评测层 | 意图准确率、答案正确率、转人工率、用户满意度 | 转人工率是核心业务指标 |
| 观测层 | 全链路 Trace + 实时告警；会话可回放 | 投诉时要能复盘”机器人说了什么” |
| 成本/安全 | 小模型兜底高频问题 + 语义缓存（FAQ 命中率高）+ 注入防御 | FAQ 高度重复，缓存命中率可观；防”诱导客服机器人越权” |
串联点：意图路由 → RAG → Guardrails → 人工兜底，是”检索对话型 Agent”的典型骨架。
案例二：数据分析 / 运维 Agent（规划+行动型，高风险）#
场景：自然语言提问 → Agent 自主查库、跑脚本、生成图表 / 执行运维操作。
| 设计层 | 决策 | 理由 / tradeoff |
|---|---|---|
| 要不要 Agent | 必须 Agent | 步骤动态：先看 schema 再写 SQL，按结果决定下一步，典型需要自主规划 |
| 架构 | Plan-and-Execute + Supervisor-Worker（Planner / SQL Worker / 图表 Worker / 运维 Worker） | 长任务先出计划再执行；多专业角色拆 Worker，新增能力只加 Worker |
| 工具层 | 查 schema / 执行 SQL（只读 vs 写分级）/ 跑脚本（沙箱）/ 执行运维命令（高危=人工审批） | 高危操作必须 Human-in-the-loop；脚本在沙箱跑限权限 |
| 记忆层 | 工作记忆存中间结果（查到的 schema、上一步 SQL 结果）；长期存常用查询模板 | 中间结果是后续步骤的输入，token 预算要管 |
| 知识层 | RAG 检索表结构文档 / 历史 SQL / runbook | 让 Agent 知道库里有什么、运维 SOP 是什么 |
| 控制层 | Reflection（SQL 跑错→读报错→改写重试）+ 结构化输出（图表配置走 Schema） | 有客观信号（SQL 能否执行）做反思判停，比自评可靠 |
| 评测层 | 任务完成率、SQL 正确率、危险操作拦截率 | 行动型 Agent 评”做对了吗”而非”答得好吗” |
| 观测层 | Trace 每步工具调用 + Checkpoint（长任务断点续跑）+ 每步可审计 | 长任务中途失败要能从断点恢复，不重跑全流程 |
| 成本/安全 | 强模型做规划、弱模型做简单子任务；最小权限 + 沙箱 + 审批是安全核心 | 行动型 Agent 风险在”误删库/误操作”，权限和审批比省钱更重要 |
串联点：Plan→Execute 循环 + Reflection 自修正 + 高危操作 HITL + Checkpoint 续跑，是”行动规划型 Agent”的典型骨架；与案例一的对比恰好覆盖 Agent 的两大类形态。
面试回答（2分钟版）
拿到 Agent 系统设计题，我不会一上来画 ReAct 循环，而是分三步走。第一步先界定要不要用 Agent——能用纯 RAG 或固定 Workflow 解决就不上 Agent，因为 Agent 的代价是不确定性，延迟高、贵、难调试；能规则化的决策比如工具选择也尽量别交给 LLM。第二步定架构和规划范式：简单交互用 ReAct，长任务用 Plan-and-Execute，多角色协作用 Supervisor-Worker。第三步是自底向上搭七层，我有个口诀叫”工记知控评观本”：工具层管 Schema 和权限分级，记忆层管三层记忆和 token 预算，知识层是 RAG 检索重排，控制层是 Reflection、结构化输出和 Guardrails 护栏，评测层是离线评测集加在线指标，观测层是 Trace、Checkpoint 和降级，最后是成本和安全层做级联缓存和多租户隔离。整个过程我会先锁定非功能需求——延迟、成本、准确率、并发、降级、合规，这些才是面试官真正想听的。举个对比，检索对话型的客服 Agent 重点在意图路由、RAG 和合规护栏，高频问题用规则和缓存兜底；而行动规划型的数据分析 Agent 重点在 Plan-Execute、工具沙箱、高危操作人工审批和 Checkpoint 断点续跑，这两类恰好覆盖 Agent 的两大形态。最后每个外部依赖我都会设退路，这是生产 Agent 和 Demo 的本质区别。
追问与易错
追问方向：
- 怎么判断该用 Agent 还是 Workflow？ → 看”下一步是否需要根据观察动态决策”：步骤固定可枚举就用 Workflow（更快更可控），需要自主规划并按中间结果调整才用 Agent。能规则化的决策不要交 LLM
- 单 Agent 和多 Agent 怎么选？ → 职责单一、工具不多用单 Agent；角色多/上下文互相干扰/需要并行专业分工才上多 Agent（Supervisor-Worker）。多 Agent 引入调度和失败传播复杂度，别过度设计
- 系统设计题你最先想清楚什么？ → 非功能需求和边界：延迟/成本/准确率/并发/降级/合规/多租户。功能谁都会列，约束和 tradeoff 才显资深
- 怎么保证生产可用而不只是 Demo？ → 三件事：每个依赖有降级退路、全链路可观测可审计、有评测集做回归。Demo 跑通 happy path，生产要扛住失败路径
- 行动型 Agent 最大的风险是什么？ → 误操作（删库、错误运维）。核心是工具最小权限 + 沙箱隔离 + 高危操作 Human-in-the-loop 审批，安全优先级高于成本
易错点：
- ❌ 上来就画 ReAct 循环 → 先界定要不要 Agent、锁非功能需求，再展开架构
- ❌ 只讲 happy path → 必须讲降级、失败传播、Checkpoint，这是资深分水岭
- ❌ 什么都交给 LLM 决策 → 可枚举的决策用规则引擎，更快更可测更便宜
- ❌ 忽略评测 → “你怎么知道它好用？“答不出评测体系直接掉档
项目实践（DocMind）： DocMind 正是按这套框架落地的检索型 Agent：用 Supervisor-Worker 编排”意图分类→混合检索(BM25+向量+RRF)→重排→生成→条件自反思”6 步流水线（七层里的知识层+控制层）；工具选择故意不交 LLM 而用 RetrievalPlanner 规则引擎（<1ms vs LLM 300ms，对应”可枚举决策走规则”）；评测层用 52 query × 4 变体 × 3 轮共 624 数据点驱动 20 轮迭代；观测层用 Langfuse 做 7 步 Trace；成本层用双模型级联+语义缓存降本约 50%。每个外部依赖都有降级（rerank 挂了走 BM25、LLM 挂了回退规则路由）。